1. Field of the Invention
The present invention relates to communications networks generally and more particularly to a method and apparatus to apply aggregate ACL/QoS features using a redirect cause.
2. Description of the Related Art
A conventional network element (e.g., switch, router, etc.) may include separate facilities or elements to perform various functions (e.g., switching/forwarding, routing, exception processing, and the like). For example, a typical router may perform packet switching using dedicated hardware (e.g., a forwarding engine) within one or more of a plurality of high-bandwidth line cards and perform more complex packet processing using software executing on a single or small number of centralized processors (e.g., one or more “route” or control processors).
A line card receiving a packet may, based on the packet's content, switch the packet to another line card or alternatively detect the need for additional processing (e.g., exception or IP options processing, packet consumption if the packet is destined for the router, etc.) and transfer the packet to memory associated with a control processor where it will be enqueued and eventually re-parsed and processed using software (e.g., express forwarding or process-level code). A packet may be redirected to a control processor as a result of a lookup (e.g., a forwarding information base (FIB) lookup or access control list (ACL) lookup) or due to an exception. Because the packet processing ability of control processors is limited, the current paradigm is to rate limit such packets before transferring them to control-processor-associated memory. Performing such rate limiting at multiple places may not be optimal in all scenarios.
Conventional networks and network elements may also provide any number of mechanisms for guaranteeing a particular quality of service (QoS) for a particular type of network traffic (e.g., traffic associated with a particular user, location, service, or application). QoS techniques may be classified into any of a number of categories including, relative priority marking, service marking, label switching, Integrated Services (IntServ)/RSVP, and static per-hop classification-type architectures. While providing a mechanism to ensure per-flow or aggregate QoS, existing QoS architectures suffer from a number of deficiencies (e.g., a lack of scalability, granularity, manageability, and/or policy control mechanisms).
Examples of the relative priority marking architecture include IPv4 precedence-marking (Postel, J., Editor, “Internet Protocol”, STD 5, RFC 791, September 1981), 802.5 Token Ring priority (ISO/IEC 8802-5 Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Common specifications—Part 5: Token Ring Access Method and Physical Layer Specifications, (also ANSI/IEEE Std 802.5-1995), 1995), and the default interpretation of 802.1p traffic classes (ISO/IEC Final CD 15802-3 Information technology—Tele-communications and information exchange between systems—Local and metropolitan area networks—Common specifications—Part 3: Media Access Control (MAC) bridges). In the relative priority marking architecture, the application, host, or proxy node selects a relative priority or “precedence” for a packet (e.g., delay or discard priority), and the network nodes along the transit path apply the appropriate priority forwarding behavior corresponding to the priority value within the packet's header.
An example of a service marking architecture is IPv4 Type of Service (TOS) (Almquist, P., “Type of Service in the Internet Protocol Suite”, RFC 1349, July 1992). In the TOS architecture, each packet is marked with a request for a “type of service”, (e.g., “minimize delay”, “maximize throughput”, “maximize reliability”, or “minimize cost”). Network nodes may then select routing paths or forwarding behaviors which are suitably engineered to satisfy the service request. The described TOS markings are very generic and do not span the entire range of possible service semantics. Furthermore, a service request is associated with each individual packet, whereas some service semantics may depend on the aggregate forwarding behavior of a sequence of packets. The service marking architecture does not easily accommodate growth in the number and range of future services (since the codepoint space is small) and involves configuration of a “TOS->forwarding behavior” association in each network node.
Examples of the label switching (or virtual circuit) architecture include Frame Relay, ATM, and MPLS (ANSI TISI, “DSSI Core Aspects of Frame Rely”, March 1990 and ATM Traffic Management Specification Version 4.0<af-tm-0056.000>, ATM Forum, April 1996). In the label switching architecture, path forwarding state and traffic management or QoS state is established for traffic streams on each hop along a network path. Traffic aggregates of varying granularity are associated with a label switched path at an ingress node, and packets/cells within each label switched path are marked with a forwarding label that is used to lookup the next-hop node, the per-hop forwarding behavior, and the replacement label at each hop.
The label switching architecture permits finer granularity resource allocation to traffic streams, since label values are not globally significant but are only significant on a single link; therefore resources can be reserved for the aggregate of packets/cells received on a link with a particular label, and the label switching semantics govern the next-hop selection, allowing a traffic stream to follow a specially engineered path through the network. This improved granularity comes at the cost of additional management and configuration requirements to establish and maintain the label switched paths. In addition, the amount of forwarding state maintained at each node scales in proportion to the number of edge nodes of the network in the best case (assuming multipoint-to-point label switched paths), and scales in proportion with the square of the number of edge nodes in the worst case, when edge-edge label switched paths with provisioned resources are employed.
The Integrated Services (IntServ)/RSVP architecture relies upon traditional datagram forwarding in the default case, but allows sources and receivers to exchange signaling messages which establish additional packet classification and forwarding state on each node along the path between them (Braden, R., Clark, D. and S. Shenker, “Integrated Services in the Internet Architecture: An Overview”, RFC 1633, July 1994 and Braden, B., Zhang, L., Berson S., Herzog, S. and S. Jamin, “Resource ReSerVation Protocol (RSVP)—Version 1 Functional Specification”, RFC 2205, September 1997). The IntServ architecture utilizes an “RSVP” protocol to guarantee QoS at a flow granularity level between a source node and a destination node of a network. A flow (sometimes also referred to as a “microflow”) is typically defined by a 5-Tuple comprising a source address, a destination address, a transport protocol, a source port number, and a destination port number.
According to the RSVP protocol, periodic messages between source and destination nodes are utilized to estimate and reserve available bandwidth for a particular flow. While the IntServ architecture integrates well with a policy infrastructure and provides fairly automatic QoS and flow-level granularity, the amount of overhead (e.g., state, signaling, classification, policing, queuing, and scheduling) required by the architecture can be significant where the network or the number of flows is large. In the absence of state aggregation, the amount of state on each node within a system implementing the IntServ architecture scales in proportion to the number of concurrent reservations, which can be large on high-speed links. The IntServ architecture also requires application support for the RSVP signaling protocol.
Similar to the previously-described 802.1p traffic class and TOS service marking architectures, the Differentiated Services (DiffServ, or DS) architecture (Nichols, K., Blake, S., Baker, F. and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”, RFC 2474, December 1998; and Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, “An Architecture for Differentiated Services”, RFC 2475 December 1998) defines levels or “classes” of service and per-hop behaviors for packets transferred across a network using a differentiated services field within a packet's TOS (IPv4) or Traffic Class (IPv6) octet and a number of architecture modules (e.g., a classifier, meter, marker, scheduler, and a dropper). More specifically, the DiffServ architecture defines a Differentiated Services Codepoint (DSCP).
Aggregate QoS services are typically applied to all packets received at a control processor from all line cards. This allows a user to classify traffic based on both Behavioral Aggregate (BA) and Multifield (MF) classifiers. One major limitation of conventional QoS architectures therefore is that a user may only apply QoS policies based on a packet's 5-Tuple or BA causing packets which match the same class map to be treated identically.